Logical Methods in Computer Science 

Vol. 7 (3:10) 2011, pp. 1-29 Submitted Jun.26, 2010 

www.lmcs-online.org Published Sep. 2, 201 1 



LOGICAL CONCURRENCY CONTROL FROM SEQUENTIAL PROOFS 

JYOTIRMOY DESHMUKH", G. RAMALINGAM', VENKATESH-PRASAD RANGANATH^ 

AND KAPIL VASWANI'^ 

" University of Texas at Austin 
e-mail address: jyotirnioy@cerc.utexas.edu 

'''"''' Microsoft Research, India 

e-mail address: graina@microsoft.com, rvprasad@microsoft.com, kapiIv@microsoft.com 



Abstract. We are interested in identifying and enforcing the isolation requirements of 
a concurrent program, i.e., concurrency control that ensures that the program meets its 
specification. The thesis of this paper is that this can be done systematically starting from 
a sequential proof, i.e., a proof of correctness of the program in the absence of concurrent 
interleavings. We illustrate our thesis by presenting a solution to the problem of making 
a sequential library thread-safe for concurrent clients. We consider a sequential library 
annotated with assertions along with a proof that these assertions hold in a sequential 
execution. We show how we can use the proof to derive concurrency control that ensures 
that any execution of the library methods, when invoked by concurrent clients, satisfies 
the same assertions. We also present an extension to guarantee that the library methods 
are linearizable or atomic. 



1. Introduction 

A key challenge in concurrent programming is identifying and enforcing the isolation re- 
quirements of a program: determining what constitutes undesirable interference between 
different threads and implementing concurrency control mechanisms that prevent this. In 
this paper, we show how a solution to this problem can be obtained systematically from 
a sequential proof: a proof that the program satisfies a specification in the absence of 
concurrent interleaving. 

Problem Setting. We illustrate our thesis by considering the concrete problem of making 
a sequential library safe for concurrent clients. Informally, given a sequential library that 
works correctly when invoked by any sequential client, we show how to synthesize concur- 
rency control code for the library that ensures that it will work correctly when invoked by 
any concurrent client. 
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Part I: Ensuring Assertions In Concurrent Executions. Consider the example in 
Figure fira). The library consists of one procedure Compute, which applies an expensive 
function / to an input variable num. As a performance optimization, the implementation 
caches the last input and result. If the current input matches the last input, the last 
computed result is returned. 



1: 


int lastNum = 0; 






A lastRes ==f(1astNum) 


2: 


int lastRes = /(O) ; 




num = * 




3: 


/* 


^returns / (num) */ 




'' lastRes == f(lastNum) 


4: 


Compute (num) { 
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/* acquire (1) ; */ 
if (lastNum==num) { 
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/* release (1) ; * 
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[7] res = lastRes 






[12] lastNum =num 
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res = /(num) ; 
/* acquire (1) ; * 
lastNum = num; 
lastRes = res; 

} 

/* release (1) ; */ 
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res ==f(num) . » 
A lastNum == num 
A lastRes == res \^^ 


, res == f(num) 
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( 1 res ==f(num) 
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return res; 






[16] return res 
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Figure 1: (a) Procedure Compute (excluding Lines 5|9|11|15" ) applies 
a (side-effect free) function /to a parameter num and caches 
the result for later invocations. Lines 5|9|11|15 contain 
a lock-based concurrency control generated by our tech- 
nique. |(b)| The control- flow graph of Compute, its edges 
labeled by statements of Compute and nodes labeled by 
proof assertions. 



This procedure works correctly when used by a sequential client, but not in the presence 
of concurrent procedure invocations. E.g., consider an invocation of Compute (5) followed 
by concurrent invocations of Compute (5) and Compute (7). Assume that the second invo- 
cation of Compute (5) evaluates the condition in Line [HI and proceeds to LinelTl Assume a 
context switch occurs at this point, and the invocation of Compute (7) executes completely, 
overwriting lastRes in LineflSJ Now, when the invocation of Compute (5) resumes, it will 
erroneously return the (changed) value of lastRes. 

In this paper, we present a technique that can detect the potential for such interfer- 
ence and synthesize concurrency control to prevent the same. The (lock-based) solution 
synthesized by our technique for the above example is shown (as comments) in Lines 5, 9, 
11, and 15 in Figure 1(a) With this concurrency control, the example works correctly even 



for concurrent procedure invocations while permitting threads to perform the expensive 
function / concurrently. 

The Formal Problem. Formally, we assume that the correctness criterion for the library is 
specified as a set of assertions and that the library satisfies these assertions in any execution 
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of any sequential client. Our goal is to ensure that any execution of the library with any 
concurrent client also satisfies the given assertions. For our running example in Figure l(a)[ 



Line [3] specifies the desired functionality for procedure Compute: Compute returns the value 
/(num). 

Logical Concurrency Control From Proofs. A key challenge in coming up with concurrency 
control is determining what interleavings between threads are safe. A conservative solution 
may reduce concurrency by preventing correct interleavings. An aggressive solution may 
enable more concurrency but introduce bugs. 

The fundamental thesis we explore is the following: a proof that a code fragment satisfies 
certain assertions in a sequential execution precisely identifies the properties relied on by 
the code at different points in execution; hence, such a sequential proof clearly identifies 
what concurrent interference can be permitted; thus, a correct concurrency control can be 
systematically (and even automatically) derived from such a proof. 

We now provide an informal overview of our approach by illustrating it for our running 



example. Figure 1(b) presents a proof of correctness for our running example (in a sequential 
setting). The program is presented as a control- flow graph, with its edges representing 
program statements. (The statement "num = *" at the entry edge indicates that the initial 
value of parameter num is unknown.) A proof consists of an invariant fj,{u) attached to 
every vertex u in the control-fiow graph (as illustrated in the figure) such that: (a) for 
every edge u ^ v labelled with a statement s, execution of s in a state satisfying /u(n) is 
guaranteed to produce a state satisfying ij,{v), (b) The invariant fj.{entry) attached to the 
entry vertex is satisfied by the initial state and is implied by the invariant /i(exit) attached 
to the exit vertex, and (c) for every edge u ^ v annotated with an assertion ip, we have 
IJ,{u) =^ (p. Condition (b) ensures that the proof is valid over any sequence of executions of 
the procedure. 

The invariant fi{u) at vertex u indicates the property required (by the proof) to hold 
at u to ensure that a sequential execution satisfies all assertions of the library. We can 
reinterpret this in a concurrent setting as follows: when a thread ti is at point u, it can 
tolerate changes to the state by another thread ^2 as long as the invariant //(it) continues 
to hold from ti's perspective; however, if another thread t2 were to change the state such 
that ti's invariant /x(n) is broken, then the continued execution by ti may fail to satisfy the 
desired assertions. 



Consider the proof in Figure 1(b) The vertex labeled x in the figure corresponds to the 
point before the execution of Line[7j The invariant attached to x indicates that the proof of 
correctness depends on the condition lastRes== f {num) being true at x. The execution of 



Line [10^ by another thread will not invalidate this condition. But, the execution of Line 13 



by another thread can potentially invalidate this condition. Thus, we infer that, when one 



thread is at point x, an execution of Line 13 by another thread should be avoided. 



We prevent the execution of a statement s by one thread when another thread is at 
a program point u (if s might invalidate a predicate p that is required at u) as follows. 
We introduce a lock ip corresponding to p, and ensure that every thread holds tp at u and 
ensure that every thread holds ip when executing s. 

Our algorithm does this as follows. From the invariant /u(u) at vertex n, we compute a 
set of predicates pm(M). (For now, think of ^{u) as the conjunction of predicates in pm(ii).) 
pm(n) represents the set of predicates required at u. For any edge u ^ v, any predicate p 
that is in pm(w) \pm(u) is required at v but not at u. Hence, we acquire the lock for p along 
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this edge. Dually, for any predicate that is required at u but not at v, we release the lock 
along the edge. As a special case, we acquire (release) the locks for all predicates in pm{u) at 
procedure entry (exit) when u is the procedure entry (exit) vertex. Finally, if the execution 
of the statement on edge u ^ v can invalidate a predicate p that is required at some vertex, 
we acquire and release the corresponding lock before and after the statement (unless it 
is already a required predicate at u or v). Note that our approach conservatively assumes 
that any two statements in the library may be simultaneously executed by different threads. 
If an analysis can identify that certain statements cannot be simultaneously executed (by 
different threads), this information can be exploited to improve the solution, but this is 
beyond the scope of this paper. 

Our algorithm ensures that the locking scheme does not lead to deadlocks by merging 
locks when necessary, as described later. Finally, we optimize the synthesized solution using 
a few simple techniques. E.g., in our example whenever the lock corresponding to lastRes 
== res is held, the lock for lastNum == num is also held. Hence, the first lock is redundant 
and can be eliminated. 

Figure [l] shows the resulting library with the concurrency control we synthesize. This 
implementation satisfies its specification even in a concurrrent setting. The synthesized 
solution permits a high degree to concurrency since it allows multiple threads to compute / 
concurrently. A more conservative but correct locking scheme would hold the lock during 
the entire procedure execution. 

A distinguishing aspect of our algorithm is that it requires only local reasoning and 
not reasoning about interleaved executions, as is common with many analyses of concurrent 
programs. Note that the synthesized solution depends on the proof used. Different proofs 
can potentially yield different concurrency control solutions (all correct, but with potentially 
different performance). 

We note that our approach has a close connection to the Owicki-Gries [18J approach 
to computing proofs for concurrent programs. The Owicki-Gries approach shows how the 
proofs for two statements can be composed into a proof for the concurrent composition 
of the statements if the two statements do not interfere with each other. Our approach 
detects potential interference between statements and inserts concurrency-control so that 
the interference does not occur (permitting a safe concurrent composition of the statements) . 

Implementation. We have implemented our algorithm, using an existing software model 
checker to generate the sequential proofs. We used the tool to successfully synthesize con- 
currency control for several small examples. The synthesized solutions are equivalent to 
those an expert programmer would use. 

Part II: Ensuring Linearizability. The above approach can be used to ensure that con- 
current executions guarantee desired safety properties, preserve data-structure invariants, 
and meet specifications (e.g., given as a precondition/postcondition pair). Library imple- 
mentors may, however, wish to provide the stronger guarantee of linearizability with respect 
to the sequential specification: any concurrent execution of a procedure is guaranteed to 
satisfy its specification and appears to take effect instantaneously at some point during its 
execution. In the second half of the paper, we show how the techniques sketched above can 
be extended to guarantee linearizability. 
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Contributions. We present a technique for synthesizing concurrency control for a hbrary 
(e.g., developed for use by a single-threaded client) to make it safe for use by concurrent 
clients. However, we believe that the key idea we present - a technique for identifying and 
realizing isolation requirements from a sequential proof ~ can be used in other contexts as 
well (e.g., in the context of a whole program consisting of multiple threads, each with its 
own assertions and sequential proofs). 

Sometimes a library designer may choose to delegate the responsibility for concurrency 
control to the clients of the library and not make the library thread-saf^ Alternatively, 
library implementers could choose to make the execution of a library method appear atomic 
by wrapping it in a transaction and executing it in an STM (assuming this is feasible). These 
are valid options but orthogonal to the point of this paper. Typically, a program is a software 
stack, with each level serving as a library. Passing the buck, with regards to concurrency 
control, has to stop somewhere. Somewhere in the stack, the developer needs to decide 
what degree of isolation is required by the program; otherwise, we would end up with a 
program consisting of multiple threads where we require every thread's execution to appear 
atomic, which could be rather severe and restrict concurrency needlessly. The ideas in this 
paper provide a systematic method for determining the isolation requirements. While we 
illustrate the idea in a simplified setting, it should ideally be used at the appropriate level 
of the software stack. 

In practice, full specifications are rarely available. We believe that our technique can 
be used even with lightweight specifications or in the absence of specifications. Consider 
our example in Fig. [l] A symbolic analysis of this library, with a harness representing a 
sequential client making an arbitrary sequence of calls to the library, can, in principle, infer 
that the returned value equals f (num) . As the returned value is the only observable value, 
this is the strongest functional specification a user can write. Our tool can be used with 
such an inferred specification as well. 

Logical interference. Existing concurrency control mechanisms (both pessimistic as well as 
optimistic) rely on a data-access based notion of interference: concurrent accesses to the 
same data, where at least one access is a write, is conservatively treated as interfence. A 
contribution of this paper is that it introduces a more logical/semantic notion of interference 
that can be used to achieve more permissive, yet safe, concurrency control. Specifically, 
concurrency control based on this approach permits interleavings that existing schemes 
based on stricter notion of interference will disallow. Hand-crafted concurrent code often 
permits "benign interference" for performance reasons, suggesting that programmers do 
rely on such a logical notion of interference. 

2. The Problem 

In this section, we introduce required terminology and formally define the problem. Rather 
than restrict ourselves to a specific syntax for programs and assertions, we will treat them 
abstractly, assuming only that they can be given a semantics as indicated below, which is 
fairly standard. 



This may be a valid design option in some cases. However, in examples such as our running example, 
this could be a bad idea. 
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2.1. The Sequential Setting. Sequential Libraries. A library £ is a pair (V,Vg), where 
"P is a set of procedures (defined below), and Vg is a set of variables, termed global variables, 
accessible to all and only procedures in V. A procedure P G V is a pair (Gp, Vp), where Gp 
is a control-flow graph with each edge labeled by a primitive statement, and Vp is a set of 
variables, referred to as local variables, restricted to the scope of P. (Note that Vp includes 
the formal parameters of P as well.) To simplify the semantics, we will assume that the set 
Vp is the same for all procedures and denote it Vl. 

Every control-flow graph has a unique entry vertex Np (with no predecessors) and a 
unique exit vertex Xp (with no successors). Primitive statements are either skip state- 
ments, assignment statements, assume statements, return statements, or assert state- 
ments. An assume statement is used to implement conditional control flow as usual. Given 
control-flow graph nodes u and v, we denote an edge from u to v, labeled with a primitive 

statement S, hy u —^ v. 

To reason about all possible sequences of invocations of the library's procedures, we 
deflne the control graph of a library to be the union of the control-flow graphs of all the 
procedures, augmented by a new vertex w, as well as an edge from every procedure exit 
vertex to w and an edge from w to every procedure entry vertex. We refer to w as the 
quiescent vertex. Note that a one-to-one correspondence exists between a path in the 
control graph of the library, starting from w, and the execution of a sequence of procedure 
calls. The edge w — t- Np from the quiescent vertex to the entry vertex of a procedure P 
models an arbitrary call to procedure P. We refer to these as call edges. 

Sequential States. A procedure-local state ai G S| is a pair (pc, a^) where pc, the program 
counter, is a vertex in the control graph and a^ is a map from the local variables Vl to their 
values. (We use "s" as a superscript or subscript to indicate elements of the semantics of 
sequential execution.) A global state ag G S^ is a map from global variables Vq to their 
values. A library state o" is a pair {ae,ag) G S| x S|. We define S* to be S| x S*. We 
say that a state is a quiescent state if its pc value is w and that it is an entry state if its pc 
value equals the entry vertex of some procedure. 

Sequential Executions. We assume a standard semantics for primitive statements that can 
be captured as a transition relation -w^ C S'* x S* as follows. Every control-flow edge e 
induces a transition relation -w^, where a-^sf^' iff cr' is one of the possible outcomes of the 
execution of (the statement labeling) the edge e in state a. The edge w — )■ Np from the 
quiescent vertex to the entry vertex of a procedure P models an arbitrary call to procedure 
P. Hence, in defining the transition relation, such edges are treated as statements that 
assign a non-deterministically chosen value to every formal parameter of P and the default 
initial value to every local variable of P. Similarly, the edge Xp -^ w is treated as a skip 
statement. We say a ^^g a' if there exists some edge e such that cj-^scr'. 

A sequential execution is a sequence of states cjocti ■ ■ ■ ak where uo is the initial state 
of the library and we have Uj -^g Ci+i for < i < k. A sequential execution represents 
the execution of a sequence of calls to the library's procedures (where the last call's exe- 
cution may be incomplete). Given a sequential execution a^ai • • • ak, we say that ctj is the 
corresponding entry state of aj if ctj is an entry state and no state at is an entry state for 
i < h < j. 

Sequential Assertions. We use assert statements to specify desired correctness properties of 
the library. Assert statements have no effect on the execution semantics and are equivalent 
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to skip statements in the semantics. Assertions are used only to define the notion of well- 
behaved executions as fohows. 

An assert statement is of the form assert 9 where, is a 1-state assertion (/? or a 
2-state assertion <l>. A 1-state assertion, which we also refer to as a predicate, makes an 
assertion about a single library state. Rather than define a specific syntax for assertions, 
we assume that the semantics of assertions are defined by a relation a \=s <p denoting that 
a state a satisfies the assertion ip. 

1-state assertions can be used to specify the invariants expected at certain program 
points. In general, specifications for procedures take the form of two-state assertions, which 
relate the input state to output state. We use 2-state assertions for this purpose. The 
semantics of a 2-state assertion $ is assumed to be defined by a relation {(Tin, (Tout) \=s ^ 
(meaning that state aout satisfies assertion $ with respect to state am)- In our examples, 
we use special input variables f *" to refer to the value of the variable v in the first state. 
E.g., the specification "x == x*" + 1" asserts that the value of x in the second state is one 
more than its value in the first state. 

Definition 2.1. A sequential execution is said to satisfy the library's assertions if for any 
transition (Tj-w^cjj+i in the execution, where e is labelled by the statement "assert 9", 
we have (a) ctj \=s if ^ is a 1-state assertion, and (b) {ain,(Ti) \=s 9 where cjj„ is the 
corresponding entry state of Uj, otherwise. A sequential library satisfies its specifications if 
every execution of the library satisfies its specifications. 

2.2. Tlie Concurrent Setting. Concurrent Libraries. A concurrent library £ is a triple 
("P, VcLk), where P is a set of concurrent procedures, Vq is a set of global variables, and 
Lk is a set of global locks. A concurrent procedure is like a sequential procedure, with the 
extension that a primitive statement is either a sequential primitive statement or a locking 
statement of the form acquire (^) or release (£) where £ is a lock. 

Concurrent States. A concurrent library permits concurrent invocations of procedures. 
We associate each procedure invocation with a thread (representing the client thread that 
invoked the procedure). Let T denote an infinite set of thread-ids, which are used as unique 
identifiers for threads. In a concurrent execution, every thread has a private copy of local 
variables, but all threads share a single copy of the global variables. Hence, the local-state in 
a concurrent execution is represented by a map from T to S|. (A thread whose local-state's 
pc value is the quiescent point represents an idle thread, i.e., a thread not processing any 
procedure invocation.) Let S^ = T — t- S| denote the set of all local states. 

At any point during execution, a lock lk is either free or held by one thread. We 
represent the state of locks by a partial function from Lk to T indicating which thread, if 
any, holds any given lock. (A lock that is not held by any thread will not be in the domain 
of the partial function.) Let T,f^ = Lk ^^ T represent the set of all lock-states. Let E^ = 
Sg X SJi^ denote the set of all global states. Let S'^ = S^ x S^ denote the set of all states. 
Given a concurrent state a = (cj£, {ag, crik)) and thread t, we define a[t] to be the sequential 
state (o-£(t), (Tg). 

Concurrent Executions. The concurrent semantics is induced by the sequential semantics as 
follows. Let e be any control-fiow edge labelled with a sequential primitive statement, and 

t be any thread. We say that {ai,{ag,aik)) -^ c (<7^, (cj^, a^fc)) iff {at,ag)'^s{(Tt,(T'g) where 
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at = ai{t) and a'^ = (T^[t i— )• a'-/]. The transitions corresponding to lock acquire/release are 
defined in the obvious way. We say that a -^c o"' iff there exists some (t,e) such that 

(t,e) , 

a -^^ c(T . 

A concurrent execution is a sequence a^ai ■ ■ ■ cr^, where o"o is the initial state of the 

library and (Tj-^cCj+i for < i < k, where the label ii = {ti,ei) identifies the executing 
thread and executed edge. We say that io- ■ ■ ik-i is the schedule of this execution. A 
sequence £o • • • ^m is a feasible schedule if it is the schedule of some concurrent execution. 
Consider a concurrent execution aoai ■ ■ ■ a^- We say that a state a-i is a t-entry-state if it 
is generated from a quiescent state by thread t executing a call edge. We say that cjj is the 
corresponding t- entry state of Gj if <Tj is a i-entry-state and no state a^ is a t-entry-state for 
i <h < j. 

We note that our semantics uses sequential consistency. Extending our results to sup- 
port weaker memory models is future work. 

Interpreting Assertions In Concurrent Executions. In a concurrent setting, assertions are 
evaluated in the context of the thread that executes the corresponding assert statement. 
We say that state a satisfies a 1-state assertion (p in the context of thread ti (denoted 
by (o", tj) \=c ^p) iff cr[ti] \=s f- For any 2-state assertion $, we say that a given pair of 
states {ain^cTout) satisfies $ in the context of thread t (denoted by {{crin,crout),t) \=c ^) iff 
{crin[t],aout[t]) \=s $• 

Definition 2.2. A concurrent execution vr is said to satisfy an assertion "assert 6" la- 

(t,e) 

belling an edge e if for any transition (7j-^cO"i+i in the execution, we have (a) ((Tj,t) \=c 9, 
if 6* is a 1-state assertion, and (b) (((7j„,o"j), t) \=c where am is the corresponding t-entry 
state of (Tj, otherwise. The execution is said to satisfy the library's specification if it satisfies 
all assertions in the library. A concurrent library satisfies its specification if every execution 
of the library satisfies its specification. 

Frame Conditions. Consider a library with two global variables x and y and a procedure 
IncX that increments x by 1. A possible specification for IncX is {x == re*" + 1) &&: (y == y*' 
The condition y == y*" is IncX's frame condition, which says that it will not modify y. Ex- 
plicitly stating such frame conditions is unnecessarily restrictive, as a concurrent update to 
y by another procedure, when IncX is executing, would be considered a violation of IncX's 
specification. Frame conditions can be handled better by treating a specification as a pair 
{S, <I>) where S is the set of all global variables referenced by the procedure, and $ is a spec- 
ification that does not refer to any global variables outside S. For our above example, the 
specification will be {{x}, x == x*" + 1)). In the sequel, however, we will restrict ourselves 
to the simpler setting and ignore this issue. 

2.3. Goals. Our goal is: Given a sequential library C with assertions satisfied in every 
sequential execution, construct C, by augmenting C with concurrency control, such that 
every concurrent execution of £ satisfies all assertions. In Section [6| we extend this goal to 
construct C such that every concurrent execution of £ is linearizable. 
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3. Preserving Single-State Assertions 

In this section we describe our algorithm for synthesizing concurrency control, but restrict 
our attention to single-state assertions. 

3.1. Algorithm Overvie'w. A sequential proof is a mapping /i from vertices of the control 
graph to predicates such that (a) for every edge e = u ^ v, {fi{u)}t{n{v)} is a valid Hoare 

triple o"! \=s fJ,{u) and <ti-^s<^2 implies a2 \=s /^(^'))) and (b) for every edge u > v, 

we have fi{u) =^ if. Note that condition (a) requires {iJ,{u)}t{n{v)} to be partially correct. 
The execution of statement t in a state satisfying fi{u) does not have to succeed. This is 
required primarily for the case when t represents an assume statement. If we want to ensure 
that the execution of a statement t does not cause any runtime error, we can simply replace 
t by "assert p; t" where p is the condition required to ensure that t does not cause any 
runtime error.) 

Note that the invariant n{u) attached to a vertex u by a proof indicates two things: 
(i) any sequential execution reaching point u will produce a state satisfying /u(it), and (ii) 
any sequential execution from point u, starting from a state satisfying /u(n) will satisfy the 
invariants labelling other program points (and satisfy all assertions encountered during the 
execution) . 

A procedure that satisfies its assertions in a sequential execution may fail to do so in a 
concurrent execution due to interference by other threads. E.g., consider a thread ti that 
reaches a program point u in a state that satisfies /u(ti). At this point, another thread t2 may 
execute some statement that changes the state to one where /i(n) no longer holds. Now, 
we no longer have a guarantee that a continued execution by ti will successfully satisfy its 
assertions. The preceding paragraph, however, hints at the interference we must avoid to 
ensure correctness: when a thread ti is at point u, we should ensure that no other thread t2 
changes the state to one where ti's invariant /u(m) fails to hold. Any change to the state by 
another thread t2 can be tolerated by ti as long as the invariant ^{u) continues to hold. We 
can achieve this by associating a lock with the invariant ^(u), ensuring that ti holds this 
lock when it is at program point u, and ensuring that any thread ^2 acquires this lock before 
executing a statement that may break this invariant. An invariant /u(ii), in general, may 
be a boolean formula over simpler predicates. We could potentially get different locking 
solutions by associating different locks with different sub-formulae of the invariant. We 
elaborate on this idea below. 

A predicate mapping is a mapping pm from the vertices of the control graph to a set 
of predicates. A predicate mapping pm is said to be a basis for a proof ^ if every /i(n) 
can be expressed as a boolean formula (involving conjunctions, disjunctions, and negation) 
over pm(u). A basis pm for proof ^ is positive if every /u(u) can be expressed as a boolean 
formula involving only conjunctions and disjunctions over pm(u). 

Given a proof ^, we say that an edge u ^ v sequentially positively preserves a predicate 
(p if {^("u) A (p}s{ip} is a valid Hoare triple. Otherwise, we say that the edge may sequentially 
falsify the predicate 93. Note that the above definition is in terms of the Hoare logic for our 
sequential language. However, we want to formalize the notion of a thread t2S execution 
of an edge falsifying a predicate (/? in a thread ti's scope. Given a predicate (/?, let (f> denote 
the predicate obtained by replacing every local variable x with a new unique variable x. 
We say that an edge u — > f may falsify ip iff the edge may sequentially falsify (p. (Note 
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that this reasoning requires working with formulas with free variables, such as x. This is 
straightforward as these can be handled just like extra program variables.) 

E.g., consider Line 13 in Fig. IT} Consider predicate lastRes==f{num). By renaming 



local variable num to avoid naming conflicts, we obtain predicate lastRes == f (num). We 



say that Line 13 may falsify this predicate because the triple {res == f{num) A lastNum 
== num A lastRes == f{num)} lastRes = res {lastRes == f{num)} is not a valid 
Hoare triple. 

Let pm be a positive basis for a proof ^ and TZ = Uupm(M). For any program point u, 
if a predicate ip is in pm(n), we say that (p is relevant at program point u. In a concurrent 
execution, we say that a predicate ip is relevant to a thread i in a given state if t is at a 
program point u in the given state and (p S pm(u). Our locking scheme associates a lock 
with every predicate <p in 7^. The invariant it establishes is that a thread, in any state, 
will hold the locks corresponding to precisely the predicates that are relevant to it. We will 
simplify the initial description of our algorithm by assuming that distinct predicates are 
associated with distinct locks and later relax this requirement. 

Consider any control-flow edge e = u — > v. Consider any predicate ip in pm(v) \ pm(u). 
We say that predicate (p becomes relevan^_j at edge e. In the motivating example, the 
predicate lastNum == num becomes relevant at Line [T2] 

We ensure the desired invariant by acquiring the locks corresponding to every predicate 
that becomes relevant at edge e prior to statement s in the edge. (Acquiring the lock after 
s may be too late, as some other thread could intervene between s and the acquire and 
falsify predicate 93.) 

Now consider any predicate ip in pm(M) \ pm(f). We say that (p becomes irrelevant at 
edge e. E.g., predicate lastRes == f (lastNum) becomes irrelevant once the false branch 
at Line [8] is taken. For every p that becomes irrelevant at edge e, we release the lock 
corresponding to p after statement s. 

The above steps ensure that in a concurrent execution a thread will hold a lock on all 
predicates relevant to it. The second component of the concurrency control mechanism is 
to ensure that any thread acquires a lock on a predicate before it falsifies that predicate. 
Consider an edge e = u — > i; in the control-flow graph. Consider any predicate (p G TZ that 
may be falsified by edge e. We add an acquire of the lock corrresponding to this predicate 
before s (unless ip G pm(ti)), and add a release of the same lock after s (unless ip £ pm(z;)). 

Managing locks at procedure entry/exit. We will need to acquire/release locks at procedure 
entry and exit differently from the scheme above. Our algorithm works with the control 
graph defined in Section [2] Recall that we use a quiescent vertex w in the control graph. 
The invariant fi{w) attached to this quiescent vertex describes invariants maintained by 

the library (in between procedure calls). Any return edge u > v must be augmented 

to release all locks corresponding to predicates in pm(M) before returning. Dually, any 
procedure entry edge w — )• n must be augmented to acquire all locks corresponding to 
predicates in pm(n). 

However, this is not enough. Let w ^ u he a procedure p's entry edge. The invariant 
fi{u) is part of the library invariant that procedure p depends upon. It is important to ensure 
that when a thread executes the entry edge of p (and acquires locks corresponding to the 



Frequently it will be the case that the execution of statement s makes predicate ip true. This is true if 
every invariant /i(«) is a conjunction of the basis predicates in pm(u). Since we allow disjunctions as well, 
this is not, however, always true. 
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basis of /u(n)) the invariant /i(n) holds. We achieve this by ensuring that any procedure 
that invahdates the invariant n{u) holds the locks on the corresponding basis predicates 
until it reestablishes n{u). We now describe how this can be done in a simplified setting 
where the invariant fi{u) can be expressed as the conjunction of the predicates in the basis 
pm(n) for every procedure entry vertex u. (Disjunction can be handled at the cost of extra 
notational complexity.) We will refer to the predicates that occur in the basis pm(n) of 
some procedure entry vertex u as library invariant predicates. 

We use an obligation mapping om(w) that maps each vertex t; to a set of library invari- 
ant predicates to track the invariant predicates that may be invalid at v and need to be 
reestablished before the procedure exit. We say a function om is a valid obligation mapping 
if it satisfies the following constraints for any edge e = u ^ v: (a) if e may falsify a library 
invariant if, then ip must be in om(f ), and (b) if (/3 G om(u), then ip must be in om(t;) unless 
e establishes if. Here, we say that an edge u — > v establishes a predicate if if {^{u)}s{ip] is 
a valid Hoare triple. Define m(n) to be pm(n) U om(n). Now, the scheme described earlier 
can be used, except that we use m in place of pm. 

Locking along assume edges. Recall that we model conditional branching, based on a con- 
dition p, using two edges labelled "assume p" and "assume !p". Any lock to be acquired 
along an assume edge will need to be acquired before the condition is evaluated. If the lock 
is required along both assume edges, this is sufficient. If the lock is not required along all 
assume edges out of a vertex, then we will have to release the lock along the edges where it 
is not required. 

Deadlock Prevention. The locking scheme synthesized above may potentially lead to a 
deadlock. We now show how to modify the locking scheme to avoid this possibility. For 
any edge e, let mbf(e) be (a conservative approximation of) the set of all predicates that 
may be falsified by the execution of edge e. We first define a binary relation ^^ on the 
predicates used (i.e., the set IZ) as follows: we say that p ^^ r iff there exists a control-flow 
edge n — > w such that p G m{u) Are {m{v) U mhf{u — > v)) \ m{u). Note that p -^^ r holds 
iff it is possible for some thread to try to acquire a lock on r while it holds a lock on p. Let 
^^* denote the transitive closure of ^^. 

We define an equivalence relation ^ on 7^ as follows: p ^ r iff p ^^* r f\r ^^* p. Note 
that any possible deadlock must involve an equivalence class of this relation. We map all 
predicates in an equivalence class to the same lock to avoid deadlocks. In addition to the 
above, we establish a total ordering on all the locks, and ensure that all lock acquisitions 
we add to a single edge are done in an order consistent with the established ordering. (Note 
that the ordering on the locks does not have to be total; a partial ordering is fine, as long 
as any two locks acquired along a single edge are ordered.) 

Improving The Solution. Our scheme can sometimes introduce redundant locking. E.g., 
assume that in the generated solution a lock ii is always held whenever a lock (.2 is acquired. 
Then, the lock I2 is redundant and can be eliminated. Similarly, if we have a predicate ip 
that is never falsified by any statement in the library, then we do not need to acquire a lock 
for this predicate. We can eliminate such redundant locks as a final optimization pass over 
the generated solution. 

Using Reader-Writer Locks. Note that a lock may be acquired on a predicate 93 for one of 
two reasons in the above scheme: either to "preserve" ip or to "break" ip. These are similar 
to read-locks and write-locks. Note that it is safe for multiple threads to simultaneously 
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hold a lock on the same predicate (p if they want to "preserve" it, but a thread that wants 
to "break" 93 needs an exclusive lock. Thus, reader-writer locks can be used to improve 
concurrency, but space constraints prevent a discussion of this extension. However, since it 
is unsafe for a thread that holds a read-lock on a predicate (/? to try to acquire a write-lock ip, 
using this optimization also requires an extension to the basic deadlock avoidance scheme. 
Specifically, it is unsafe for a thread that holds a read-lock on a predicate 99 to try to 
acquire a write-lock 93, as this can lead to a deadlock. Hence, any acquisition of a lock 
on a predicate 93 (to preserve it) should be made an exclusive (write) lock if along some 
execution path it may be necessary to promote this lock to a write lock before the lock is 
released. 

Generating Proofs. The sequential proof required by our scheme can be generated using 
verification tools such as SLAM [2J, BLAST [Tr,T2] or Yogi [lOj. Predicate abstraction [2] 
is a program analysis technique that constructs a conservative, finite state abstraction of a 
program with a large (possibly infinite) state space using a set of predicates over program 
variables. Tools such as SLAM and BLAST use predicate abstraction to check if a given 
program P satisfies a specification (p. The tools start with a simple initial abstraction and 
iteratively refine the abstraction until the abstraction is rich enough to prove the absence 
of a concrete path from the program's initial state to an error state (or a real error is 
identified) . 

For programs for which verification succeeds, the final abstraction produced, as well as 
the result of abstract interpretation using this abstraction, serve as a good starting point 
for constructing the desired proof. The final abstraction consists of a predicate map pm 
which maps each program point to a set of predicates and as well as a mapping from each 
program statement to a set of abstract predicate transformers which together define an 
abstract transition system. Furthermore, abstract interpretation utilizing this abstraction 
effectively computes a formula /i(u) over the set of predicates pm(ti) at every program point 
u that conservatively describes all states that can arise at program point u. 

The map /i constitutes a proof of sequential correctness, as required by our algorithm, 
and the predicate map pm is a valid basis for the proof. The map pm can be extended 
into a positive basis for the proof easily enough. Since a minimal proof can lead to better 
concurrency control, approaches that produce a "parsimonious proof" (e.g., see [12]) are 
preferable. A parsimonious proof is one that avoids the use of unnecessary predicates at 
any program point. 

3.2. Complete Schema. We now present a complete outline of our schema for synthesizing 
concurrency control. 

(1) Construct a sequential proof /i that the library satisfies the given assertions in any 
sequential execution. 

(2) Construct positive basis pm and an obligation mapping om for the proof //. 

(3) Compute a map mbf from the edges of the control graph to TZ, the range of pm, such 
that mbf(e) (conservatively) includes all predicates in IZ that may be falsified by the 
execution of e. 

(4) Compute the equivalence relation T^ on IZ. 

(5) Generate a predicate lock allocation map im : TZ ^ C such that for any ipi «^ 992, we 
have im{Lpi) = [m(v32)- 
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(6) Compute the following quantities for every edge e = u ^ v, where we use im{X) as 
shorthand for { lxn{p) \ p e X } and m(n) = pm(u) U om(u): 

BasisLocksAcq{e) = [m(m(f)) \ [m(m(u)) 
BasisLocksRel{e) = [m(m(u)) \ [tn(m(f)) 
BreakLocks{e) = [m(mbf(e)) \ [m(m(u)) \ lm(m(t;)) 

(7) We obtain the concurrency-safe library C by transforming every edge u — > v in the 
library £ as follows: 

(a) V p G BasisLocksAcq{u — > v), add an acquire ([m(p)) before s; 

(b) V p G BasisLocksRel{u — > v), add a release([m(p)) after s; 

(c) V p G BreakLocks{u — > v), add an acquire ([m(j))) before s and a release((m(p)) 
after s. 

All lock acquisitions along a given edge are added in an order consistent with a total 
order established on all locks. 



3.3. Correctness. We now present a formal statement of the correctness claims for our 
algorithm. Let £ be a given library with a set of embedded assertions satisfied by all 
sequential executions of £. Let C be the library obtained by augmenting C with concurrency 



control using the algorithm presented in Section 3.2 Let fj,, pm, and om be the proof, the 
positive basis, and the obligation map used to generate C. 

Consider any concurrent execution of the given library C. We say that a thread t is safe 
in a state a if (a, t) \=c fJ-iu) where t's program-counter in state a is u. We say that thread 
t is active in state a if its program-counter is something other than the quiescent vertex. 
We say that state a is safe if every active thread t in a is safe. Recall that a concurrent 

execution is of the form: uq -^ ai -^ • • • cr„, where each label ii is an ordered pair (t, e) 
indicating that the transition is generated by the execution of edge e by thread t. We say 
that a concurrent execution is safe if every state in the execution is safe. It trivially follows 
that a safe execution satisfies all assertions of C 

Note that every concurrent execution vr of £ corresponds to an execution vr' of £ if 
we ignore the transitions corresponding to lock acquire/release instructions. We say that 
an execution vr of £ is safe if the corresponding execution vr' of £ is safe. The goal of the 
synthesized concurrency control is to ensure that only safe executions of £ are permitted. 

(t,e) 

We say that a transition a — '■ — > a' preserves the basis of an active thread t' ^ t whose 
program-counter in state a is n if for every predicate ip £ pm{u) the following holds: if 

(o", t') \=c (f, then {(t' ,t') \=c ^p- We say that a transition a — '■ — > a' ensures the basis of 
thread t if either e = x — )• y is not the procedure entry edge or for every active thread 
t' ^t whose program-counter in state a Ss u and for every predicate 99 G pm(w) none of the 
predicates in pm(y) are in om(M). 

(t,e) 

We say that a transition o — '■ — > a' is basis-preserving if it preserves the basis of every 
active thread t' ^ t and ensures the basis of thread t. A concurrent execution is said to be 
basis-preserving if all transitions in the execution are basis-preserving. 

Lemma 3.1. (a) Any basis-preserving concurrent execution of C is safe, (b) Any concurrent 
execution of £ corresponds to a basis-preserving execution of £. 
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Proof, (a) We prove that every state in a basis-preserving execution of C is safe by induction 
on the length of the execution. 

Consider a thread t in state a with program-counter value u. Assume that t is safe 
in a. Thus, {a,t) \=c iJ-iu). Note that fj,{u) can be expressed in terms of the predicates in 
pm(n) using conjunction and disjunction. Let SP denote the set of all predicates 93 in pm(n) 
such that {a, t) \=c (p. Let a' be any state such that {a' , t) |=c (/? for every if € SP. Then, it 
follows that t is safe in a' . Thus, it follows that after any basis-preserving transition every 
thread that was safe before the transition continues to be safe after the transition. 

We now just need to verify that whenever an inactive thread becomes active (represent- 
ing a new procedure invocation), it starts off being safe. We can establish this by inductively 
showing that every library invariant must be satisfied in a given state or must be in om(n) 
for some active thread t at vertex u. 

(b) Consider a concurrent execution of C. We need to show that every transition in 
this execution, ignoring lock acquires/releases, is basis-preserving. This follows directly 

(t,e) 

from our locking scheme. Consider a transition a — '- — > a' . Let t' 7^ i be an active thread 
whose program-counter in state o is u. For every predicate (f> G pm(tt) U om(n), our scheme 
ensures that t' holds the lock corresponding to (/?. As a result, both the conditions for 
preserving basies are satisfied. D 

Theorem 3.2. (a) Any concurrent execution of C satisfies every assertion of C. (h) The 
library C is deadlock- free. 



Proof, (a) This follows immediately from Lemma 3.1 

(b) This follows from our scheme for merging locks and can be proved by contradiction. 
Assume that a concurrent execution of C produces a deadlock. Then, we must have a set 
of threads ti to tk and a set of locks £1 to £k such that each ti holds lock ii and is waiting 
to acquire lock ^i©i, where i © 1 denotes (i mod k) + 1. In particular, ti must hold lock 
ii because it wants a lock on some predicate pi, and must be trying to acquire lock £i^i 
because of some predicate (7j©i. Thus, we must have qi ^ pi and pi ^-> qi^i for every i. 
This implies that all of pi and Qi must be in the same equivalence class of ^ and, hence, £1 
through £fc must be the same, which is a contradiction (since we must have k > 1 to have 
a deadlock). D 

As mentioned earlier, our synthesis technique has a close connection to Owicki-Gries |18| 
approach to verifying concurrent programs. An alternative approach to proving Theo- 
rem |3.2[ a) would be to construct a suitable Owicki-Gries style proof for the library. We 
believe that this is doable. 

4. Handling 2-State Assertions 

The algorithm presented in the previous section can be extended to handle 2-state assertions 
via a simple program transformation that allows us to treat 2-state assertions (in the original 
program) as single-state assertions (in the transformed program). We augment the set of 
local variables with a new variable v for every (local or shared) variable v in the original 
program and add a primitive statement CV at the entry of every procedure, whose execution 
essentially copies the value of every original variable v to the corresponding new variable v. 
Let (/ denote the projection of a transformed program state a' to a state of the original 
program obtained by forgetting the values of the new variables. Given a 2-state assertion $, 
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Library 


Description 


compute. c 


See Figure 


T 




reduce.c 


See Figure 


3 




increment. c 


See Figure 


4 




average.c 


Two procedures that compute the running sum and average of a 
sequence of numbers 


device -Cache. c 


One procedure that reads data from a device and caches the data 
for subsequent reads [7] . The specification requires quantified pred- 
icates. 


server-Store. c 


A hbrary derived from a Java implementation of Simple Authen- 
tication and Security Layer (SASL). The library stores security 
context objects for sessions on the server side. 



Table 1: Benchmarks used in our evaluation. 

let $ denote the single-state assertion obtained by replacing every u*" by v. As formalized 
by the claim below, the satisfaction of a 2-state assertion $ by executions in the origi- 
nal program corresponds to satisfaction of the single-state assertion ^ in the transformed 
program. 

Lemma 4.1. 

(1) A schedule ^ is feasible in the transformed program iff it is feasible in the original 
program. 

(2) Let a' and a be the states produced by a particular schedule with the transformed and 
original programs, respectively. Then, a = a!_. 

(3) Let it' and vr be the executions produced by a particular schedule with the transformed and 
original program, respectively. Then, vr satisfies a single-state assertion tp iff n' satisfies 
it. Furthermore, vr satisfies a 2-state assertion $ iff ir' satisfies the corresponding one- 
state assertion <5. 

Synthesizing concurrency control. We now apply the technique discussed in Section [3] to 
the transformed program to synthesize concurrency control that preserves the assertions 
transformed as discussed above. It follows from the above Lemma that this concurrency 
control, used with the original program, preserves both single-state and two-state assertions. 



5. Implementation 

We have built a prototype implementation of our algorithm. Our implementation takes a 
sequential library and its assertions as input. It uses a pre-processing phase to combine the 
library with a harness that simulates the execution of any possible sequence of library calls 
to get a complete C program. (This program corresponds to the control graph described 
in Section ^) It then uses a verification tool to generate a proof of correctness for the 
assertions in this program. We use the predicate-abstraction based software verification 
tool Yogi described in ^ to generate the required proofs. We modified the verifier to emit 
the proof from the final abstraction, which associates every program point with a boolean 
formula over predicates. It then uses the algorithm presented in this paper to synthesize 
concurrency control for the library. It utilizes the theorem prover Z3 [5j to identify the 
statements in the program whose execution may falsify relevant predicates. 
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We used a set of benchmark programs to evaluate our approach (Table [T]) . We also 
applied our technique manually to two real world libraries, a device cache library |7], and 
a C implementation of the Simple Authentication and Security Layer (SASL). The proofs 
for the device cache library and the SASL library require quantified predicates, which were 
beyond the scope of the verifier we used. 

In all these programs, the concurrency control scheme we synthesized was identical to 
what an experienced programmer would generate. The concurrency control we synthesized 
required one lock for all libraries, with the exception of the SASL library, where our solution 
uses two locks. Our solutions permit more concurrency as compared to a naive solution 
that uses one global lock or an atomic section around the body of each procedure. For 
example, in case of the server store library, our scheme generates smaller critical sections 
and identifies a larger number of critical sections that acquire different locks as compared 
to the default implementation. For these examples, the running time of our approach is 
dominated by the time required to generate the proof; the time required for the synthesis 
algorithm was negligible. 

The source code for all our examples and their concurrent versions are available online 
at [I]. Note that our evaluation studies only small programs. We leave a more detailed 
evaluation of our approach as future work. 

6. Concurrency Control For Linearizability 

6.1. The Problem. In the previous section, we showed how to derive concurrency control 
to ensure that each procedure satisfies its sequential specification even in a concurrent 
execution. However, this may still be too permissive, allowing interleaved executions that 
produce counter-intuitive results and preventing compositional reasoning in clients of the 
library. E.g., consider the procedure Increment shown in Fig.[2j which increments a shared 
variable x by 1. The figure shows the concurrency control derived using our approach to 
ensure specification correctness. Now consider a multi-threaded client that initializes x 
to and invokes Increment concurrently in two threads. It would be natural to expect 
that the value of x would be 2 at the end of any execution of this client. However, this 
implementation permits an interleaving in which the value of x at the end of the execution is 
1: the problem is that both invocations of Increment individually meet their specifications, 
but the cumulative effect is unexpecteqj 

This is one of the difficulties with using pre/post-condition specifications to reason 
about concurrent executions. 

One solution to this problem is to apply concurrency control synthesis to the code (li- 
brary) that calls Increment. The synthesis can then detect the potential for interference 
between the two calls to Increment and prevent them from happening concurrently. An- 
other possible solution, which we explore in this section, is for the library to guarantee a 
stronger correctness criteria called linearizability |13j . Linearizability gives the illusion that 
in any concurrent execution, (the sequential specification of) every procedure of the library 
appears to execute instantaneously at some point between its call and return. This illusion 
allows clients to reason about the behavior of concurrent library compositionally using its 



•^ We conjecture that such concerns do not arise when the specification does not refer to global variables. 
For instance, the specification for our example in Fig. [T] does not refer to global variables, even though the 
implementation uses global variables. 
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1 int X = 0; 

2 / /©ensures x —— a;™ + 1 A returns x 

3 Increment () { 

4 int tmp ; 

5 acquire (Z(^^^^i„) ) ; tmp = x; release (/(^.^^^.i^) ) ; 

6 tmp = tmp + 1 ; 

7 acquire (Z(^^^^in) ) ; x = tmp; release (/(^.^^^.i^) ) ; 

8 return tmp ; 

9 > 

Figure 2: A non-linearizable implementation of the procedure Increment 

sequential specifications. In this section, we show how our approach presented earlier for 
synthesizing a logical concurrency control can be adapted to derive concurrency control 
mechanisms that guarantee linearizability. 

6.1.1. Linearizability. We now extend the earlier notation to define linearizability. Lineariz- 
ability is a property of the library's externally observed behavior. A library's interaction 
with its clients can be described in terms of a history, which is a sequence of events, where 
each event is an invocation event or a response event. An invocation event is a tuple con- 
sisting of the procedure invoked, the input parameter values for the invocation, as well as a 
unique identifier. A response event consists of the identifier of a preceding invocation event, 
as well as a return value. Furthermore, an invocation event can have at most one matching 
response event. A complete history has a matching response event for every invocation 
event. Note that an execution, as defined in Section [2| captures the internal execution steps 
performed during a procedure execution. A history is an abstraction of an execution that 
captures only procedure invocation and return steps. 

A sequential history is an alternating sequence invi, n, • • • , invn, rn of invocation events 
and corresponding response events. We abuse our earlier notation and use a + invi to denote 
an entry state corresponding to a procedure invocation consisting of a valuation a for the 
library's global variables and a valuation invi for the invoked procedure's formal parameters. 
We similarly use a + r^ to denote a procedure exit state with return value rj. Let o"o denote 
the value of the globals in the library's initial state. Let $j denote the specification of 
the procedure invoked by invi. A sequential history is legal if there exist valuations o"i, 
1 < i < n, for the library's globals such that (crj_i + invi, Gi + rj) \=s $j for 1 <i <n. 

A complete interleaved history H is linearizable if there exists some legal sequential 
history S such that (a) H and S have the same set of invocation and response events 
and (b) for every return event r that precedes an invocation event inv in H, r and inv 
appear in that order in 5 as well. An incomplete history H is said to be linearizable if 
the complete history H' obtained by appending some response events and omitting some 
invocation events without a matching response event is linearizable. 

Finally, a library C is said to be linearizable if every history produced by C is lineariz- 
able. 

The concept of a linearization point is often used in explanations and proofs of correct- 
ness of linearizable algorithms. Informally, a linearization point is a point (or control-flow 
edge) inside the procedure such that the procedure appears to execute atomically when it 
executes that point. Our eventual goal is to parameterize our synthesis algorithm with a 
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linearization point specification (a description of tlie point or points we wish to serve as 
the Hnearization point). In this paper, however, we treat the procedure entry edge as the 
linearization point and will refer to it as the linearization point. 

6.1.2. Implementation As A Specification and Logical Serializability. The techniques we 
present in this section actually guarantee linearizability with respect to the given sequential 
implementation (i.e., treating the sequential implementation as a sequential specification). 
In particular, this approach guarantees that the concurrent execution will return the same 
values as some sequential execution. (The word atomicity is sometimes used to describe this 
behavior.) Such an approach has both advantages as well as disadvantages. The advantage 
is that the technique is more broadly applicable, in practice, as it does not require a user- 
provided specification. The disadvantage is that, in theory, the sequential implementation 
may be more restrictive than the intended specification. Hence, preserving the sequential 
implementation behavior may unnecessarily restrict concurrency. 

The properties of atomicity and linearizability relate to the externally observed behavior 
of the library (i.e., the behavior as seen by clients of the library). The implementation 
technique we use also guarantees certain properties about the internal (execution) behavior 
of the library, which we explain now. 

Recall that an execution, as defined in Section [2| captures the internal execution steps 
performed during a procedure execution while a history is an abstraction of an execution 
that captures only procedure invocation and return steps. 

(i,e) 

Recall that every transition a-^g'^' is labelled by a pair (t, e), indicating that the tran- 
sition was created by the execution of edge e by thread t. We refer to a pair of the form 
(i,e) as a step. A schedule C is a sequence of steps ii,--- ,ik- We say that a schedule 

ii,- ■ ■ ,ik is feasible if there exists an execution ao'^cO'i ■ ■ ■ '^cO'k^ where (Tq is the initial 
program state. Given an execution vr = (To-^c<7i • • • ~^cO'k, the sub-schedule of t in vr is the 
sequence is-i,- " > ^sn of steps executed by t in vr. 

A procedure invocation ti is said to precede another procedure invocation ^2 in an 
execution if ti completes before ^2 begins. 

Two complete executions are said to be observationally-equivalent if they consist of 
the same set of procedure invocations and for each procedure invocation the return values 
are the same in both executions. An execution tti is said to be a permutation of another 
execution tt2 if for every thread (procedure invocation) t the sub-schedule of t in vri and 7r2 
are the same. An execution vri is said to be topologically consistent with another execution 
7r2 if for every pair of procedure invocations ti and t2, if ti precedes t2 in tti then ti precedes 
t2 in TT2 as well. 

Our goal is to synthesize a concurrency control mechanism that permits only executions 
that are observationally-equivalent, topologically consistent, permutations of sequential ex- 
ecutions. We note that this concept is similar to various notions of serializability [25] (com- 
monly used in database transactions). The new variant we exploit may be thought of as 
logical serializability: corresponding points in the compared executions satisfy equivalence 
with respect to certain predicates of interest, as determined by the basis. 

6.1.3. Terminology. In this section, we will use a modified notion of basis introduced in 
Section [3l 
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The key idea we explore in this paper is that of precisely characterizing what is relevant 
to a thread at a particular point and using this information to derive a concurrency control 
solution. In the previous sections, we captured the relevant information as an invariant or 
set of predicates (the basis). In this section, we will find it necessary to mark certain values 
(e.g., the value of a variable at a particular program point) as relevant as well. In order 
to seamlessly reason about such relevant values (e.g., of type integer) along with relevant 
predicates, we utilize symbolic predicates to encode the relevance of values. 

In the sequel, note that we consider two predicates to be equal only if they are syntac- 
tically equal. 

A symbolic predicate is one that utilizes auxiliary (logical) variables. As an example, 
given program variable x and a logical variable w, we will make use of predicates such 
as "x = w" . Such symbolic predicates can be manipulated just like normal predicates 
(e.g., in computing weakest-precondition). Conceptually, such a symbolic predicate can be 
interpreted as a short-hand notation for the (possibly infinite) family of predicates obtained 
by replacing the logical variable w by every possible value it can take. Thus, if x and w are 
of type T, then the above symbolic predicate represents the set of predicates {x = c | c G T}. 
Note that this set of predicates captures the value of x: i.e., we know the value of every 
predicate in this set iff we know the value of x. This trick lets us use the symbolic predicate 
"x = w" to indicate that the value of x is relevant to a thread (and, hence, should not be 
modified by another thread). 

Given any predicate (/?, let ip* denote the set of predicates it represents (obtained by 
instantiating the logical variables in ^p as explained above). (Thus, for a non-symbolic 
predicate f, (p* = {(/?}.) We say that (pi and ip2 are equivalent if (/?* = ip2- E.g., if w 
ranges over all integers, then "x = w" and "x = w + 1" are equivalent predicates. Predicate 
equivalence can be used to simplify a set of predicates or a basis. Given a set of predicates 
S, let S* represent the set of predicates U{ip* \ ip £ S}. If 5^ = ^2, then it is safe, in the 
sequel, to replace the set Si by the set 5*2 in a basis. This may be critical in creating finite 
representations of certain basis. 

We say that a predicate ip is covered by a set of predicates 5 if 93 can be expressed as 
a boolean formula over the predicates in S using conjunctions and disjunctions. 

Recall that a predicate mapping is a mapping pm from the vertices of the control graph 
to a set of predicates. 

We say that a predicate mapping pm is wp-closed if for every edge e = u — > v and for 
every ip G pTn(f ), (a) If e is not the entry edge of a procedure, then the weakest-precondition 
of (/? with respect to s, wp{s, ip) is covered by pm(u), and (b) If e is the edge w — )■ Np from the 
quiescent vertex to the entry vertex of P, then 93' is covered by pm(u;), where (/?' is obtained 
by replacing the occurrence of any procedure parameter Xi by a new logical variable x'^. 

Finally, we say that a predicate mapping is closed if it is wp-closed and if for every vertex 
u and every predicate ip in pm(u), the negation of p is also in pm(n). The later condition 
helps us reuse the algorithm description from Section [3] in spite of some differences in the 
context. 

Without loss of generality, we assume that each procedure Pj returns the value of a 
special local variable retj. 

6.2. The Synthesis Algorithm. We now show how our approach can be extended to 
guarantee linearizability or atomicity. We use a few tricky cases to motivate the adaptations 
we use of our previous algorithm. 
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We start by characterizing non-linearizable interleavings permitted by our earlier ap- 
proach. We classify the interleavings based on the nature of linearizability violations they 
cause. For each class of interleavings, we describe an extension to our approach to generate 
additional concurrency control to prohibit these interleavings. Finally, we prove correctness 
of our approach by showing that all interleavings we permit are linearizable. 

6.2.1. Delayed Falsification. The first issue we address, as well as the solution we adopt, 
are not surprising from a conventional perspective. (This extension is, in fact, the analogue 
of two-phase locking: i.e., the trick of acquiring all locks before releasing any locks to avoid 
interference.) Informally, the problem with the Increment example can be characterized as 
"dirty reads" and "lost updates" : the second procedure invocation executes its linearization 
point later than the first procedure invocation but reads the original value of x, instead 
of the value produced by the the first invocation. Dually, the update done by the first 
procedure invocation is lost, when the second procedure invocation updates x. From a 
logical perspective, the second invocation relies on the invariant x == x*" early on, and 
the first invocation breaks this invariant later on when it assigns to x (at a point when the 
second invocation no longer relies on the invariant). This prevents us from reordering the 
execution to construct an equivalent sequential execution (while preserving the proof). To 
achieve linearizability, we need to avoid such "delayed falsification" . 

The extension we now describe prevents such interference by ensuring that instructions 
that may falsify predicates and occur after the linearization point appear to execute atomi- 
cally at the linearization point. We achieve this by modifying the strategy to acquire locks 
as follows. 

• We generalize the earlier notion of may-falsify. We say that a path may-falsify a predicate 
if if some edge in the path may-falsify 99. We say that a predicate ip m,ay-be- falsified- after 
vertex u if there exists some path from u to the exit vertex of the procedure that does 
not contain any linearization point and may-falsify ip. 

• Let mf be a predicate map such that for any vertex u, mf{u) includes any predicate that 

may-be- falsified-after u. 

g 

• We generalize the original scheme for acquiring locks. We augment every edge e = u —^ v 

as follows: 

(1) V £ G [m(mf(u))\[m(mf(n)), add an "acquire(£)" before S 

(2) V £ G [m(mf(w))\[m(mf(f)), add an "release(^)" after S 

This extension suffices to produce a linearizable implementation of the example in Fig. [2| 

6.2.2. Return Value Interference. We now focus on interference that can affect the actual 
value returned by a procedure invocation, leading to non-linearizable executions. 

Consider procedures IncX and IncY in Fig. [31 which increment variables x and y re- 
spectively. Both procedures return the values of x and y. However, the postconditions of 
IncX (and IncY) do not specify anything about the final value of y (and x respectively). Let 
us assume that the linearization points of the procedures are their entry points. Initially, 
we have x = y = 0. Consider the following interleaving of a concurrent execution of the two 
procedures. The two procedures execute the increments in some order, producing the state 
with X = y = 1. Then, both procedures return (1,1). This execution is non-linearizable 
because in any legal sequential execution, the procedure executing second is obliged to re- 
turn a value that differs from the value returned by the procedure executing first. The 
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int X , y ; 
IncXO { 

acquire (/^^^^i„) ; 

X = X + 1; 

(refii ,reii2) = (x,y) ; 

release (Z^^^j.i,i) ; 

} 
IncYO { 

acquire (/y^^yi„) ; 

y = y + 1; 

(ret2i,rei22) = (x,y) ; 



release (Z„ 



.); 



} 



(a) 



int X , y ; 

©ensures x = x*" + 1 

©returns {x, y) 

IncXO { 

[retii==x+l A ret'i2==y'\ 

CT : yi = X™ 
[x==x'" A reiii==x+l A reti2=y] 

X = X + 1; 
[x==x'"+l A r-eiii==x A reti2= y] 

(retii,reti2) = (x,y) ; 
[x==x'"+l A retii==reiii 
A r-eii2==refi2] 



} 



(b) 



int X, y; 
IncXO { 

acquire (Z^erjeii) ; 

X = x+1; 

(r-eiii,reti2) = (x,y) ; 

} 

IncYO { 

acquire (Z„erjeii) ; 

y = y+1; 
(r-ei2i,ret22) = (x,y) ; 



} 



(c) 



Figure 3: An example illustrating return value interference. Both procedures 
return (x,y) . retij refers to the j^^ return variable of the i*'^ 



proce- 



dure. Figure 3(a) is a non-linearizable implementation synthesized 
using the approach described in Section [3} Figure |3(b)| shows the 
extended proof of correctness of the procedure IncX and Figure [3 (c 
shows the linearizable implementation. 



left column in Figure [3] shows the concurrency control derived using our approach with 
previously described extensions. This is insufficient to prevent the above interleaving. This 
interference is allowed because the specification for IncX allows it to change the value of y 
arbitrarily; hence, a concurrent modification to y by any other procedure is not seen as a 
hindrance to IncX. 

To prohibit such interferences within our framework, we need to determine whether 
the execution of a statement s can potentially affect the return-value of another procedure 
invocation. We do this by computing a predicate </>(rei') at every program point u that 
captures the relation between the program state at point u and the value returned by the 
procedure invocation eventually (denoted by ret'). We then check if the execution of a 
statement s will break predicate 4){ret'), treating ret' as a free variable, to determine if the 
statement could affect the return value of some other procedure invocation. 

Formally, we assume that each procedure returns the value of a special variable ret. 
(Thus, "return exp" is shorthand for "rei = exp" .) We introduce a special auxiliary 
variable ret'. We say that a predicate map pm covers return statements if for every edge 
u ^ V labelled by a return statement "return exp" the set pm(n) covers the predicate 
ret' == ret. (See the earlier discussion in Section 6.1.3 about such symbolic predicates and 



how they encode the requirement that the value of ret at a return statement is relevant and 
must be preserved.) 

By applying our concurrency-control synthesis algorithm to a closed basis that covers 
return statements, we can ensure that no return-value interference occurs. 

The middle column in Figure |3] shows the augmented sequential proof of correctness of 
IncX. The concurrency control derived using our approach starting with this proof is shown 
in the third column of Fig. [31 The lock Imerged denotes a lock obtained by merging locks 
corresponding to multiple predicates simultaneously acquired/released. It is easy to see 
that this implementation is linearizable. Also note that if the shared variables y and x were 
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1 int X , y ; 

2 / /©ensures y = y"^ + I 

3 IncYO { 

4 [true] CP : y'" = y 

5 [y==yn y = y + i; 

6 [y == y- + 1] 

7 > 



1 


/ /©ensures 


X <y 




2 


ReduceXO 


i 




3 


[irwe] £P 






4 


[true] if 


(x > 


y) 


5 


[irue] X 


= y - 


1 


6 


} 






7 


[x<y] 







Figure 4: An example illustrating interference in control flow. Each line is annotated 
square braces) with a predicate the holds at that program point. 



m 



not returned by procedures IncX and IncY respectively, we will derive a locking scheme 
in which accesses to x and y are protected by different locks, allowing these procedures to 
execute concurrently. 



6.2.3. Control Flow Interference. An interesting aspect of our scheme is that it permits 
interference that alters the control flow of a procedure invocation if it does not cause the 
invocation to violate its specification. Consider procedures ReduceX and IncY shown in 
Fig. [4} The specification of ReduceX is that it will produce a final state where x < y, while 
the specification of IncY is that it will increment the value of y by 1. ReduceX meets its 
specification by setting x to be y — 1, but does so only if x > y. 

Now consider a client that invokes ReduceX and IncY concurrently from a state where 
X = y = 0. Assume that the ReduceX invocation enters the procedure. Then, the invocation 
of IncY executes completely. The ReduceX invocation continues, and does nothing since 
X < y at this point. 

Figure |4] shows a sequential proof and the concurrency control derived by the scheme 
so far, assuming that the linearization points are at the procedure entry. A key point to 
note is that ReduceX's proof needs only the single predicate x < y. The statement y = y + 1 
in IncY does not falsify the predicate x < y; hence, IncY does not acquire the lock for this 
predicate. This locking scheme permits IncY to execute concurrently with ReduceX and 
affect its control flow. While our approach guarantees that this control flow interference 
will not cause assertion violations, proving linearizability in the presence of such control 
flow interference, in the general case, is challenging (and an open problem). 

We now describe how our technique can be extended to prevent control flow interference, 
which suffices to guarantee linearizability. 

We ensure that interference by one thread does not affect the execution path another 
thread takes. We say that a basis pm covers the branch conditions of the program if for 
every branch edge u — t- u, the set pm{u) covers the assume condition in s. If we synthesize 
concurrency control using a closed basis pm that covers the branch conditions, we can ensure 
that no control-fiow interference happens. 

In the current example, this requires predicate x > y to be added to the basis for 
ReduceX. As a result, ReduceX will acquire lock lx>y at entry, while IncY will acquire the 
same lock at its linearization point and release the lock after the statement y = y + 1. It is 
easy to see that this implementation is linearizable. 
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6.2.4. The Complete Schema. In summary, our schema for synthesizing concurrency control 
that guarantees hnearizabihty is as follows. 

First, we determine a closed basis for the program that covers all return statements and 
branch conditions in the program. (Such a basis is the analogue of the proof and basis used 
in Section [3j An algorithm for generating such a basis is beyond the scope of this paper. 
Such a basis can be computed by iteratively computing weakest-preconditions, but, in the 
general case, subsumption and equivalence among predicates will need to be utilized to 
simplify basis sets to ensure termination.) We then apply the extended concurrency control 
synthesis algorithm described in Section [6.2.1 



6.3. Correctness. The extensions described above to the algorithm of Sections [3] and [4] 
for synthesizing concurrency control are sufficient to guarantee hnearizabihty, as we show 
in this section. 

Let cr be a program state. We define TBP(c7, t) to be the set {ip G (pm(n))* | (a, t) \=c (p} 



where t's program-counter in state a is u. (See Section 6.1.3 for the definition of S* for any 
set of predicates S.) 

(t,e) 

Lemma 6.1. Let pm he a wp-closed predicate map. Consider transitions o'i-~^cO'2 cind 
o-3^1o-4. //TBP(CTi,t) 5 TBP(o-3,t), then TBP(o-2,t) 5 TBP(o-4,t). 

Proof. Let e be the edge u —^ v. Note that for every predicate ip G pxn{v), the weakest- 
precondition of ip with respect to the statement S can be expressed in terms of the predicates 
in pm{u) using conjunction and disjunction (by definition of a wp-closed predicate map). 
The result follows. D 

Consider any concurrent execution vri produced by a schedule ^. We assume, without 
loss of generality, that every procedure invocation is executed by a distinct thread. Let 
ti, . . . , tfc denote the set of threads which complete execution in the given schedule, ordered 
so that ti executes its linearization point before tj+i. We show that ^ is linearizable by 
showing that S, is equivalent to a sequential execution of the specifications of the threads 
ti, . . . , tfc executed in that order. 

Let ^i denote a projection of schedule ^ consisting only of execution steps by thread ti. 
Let C denote the schedule ^i- • • Ck- 

Lemma 6.2. (^ is a feasible schedule. Furthermore, for any corresponding execution steps 

(Tj-^cO"j+i cLnd (^k'^c(^'k+i ^f ^^^ ^"^^ executions, we have TBP(o"j,t) 5 TBP((T^,t). 

Proof. Proof by induction over the execution steps of C. 

The claim is trivially true for the first step of C, since the initial state in the same in 
both executions. 

(t,e') (i,e) 

Now, consider any pair of "candidate" successive execution steps o"^_i •^cC^-^cO'fc+i of 
(. That is, we assume, from our inductive hypothesis, that the first execution step above is 
feasible, but we need to establish that the second step is a feasible execution step. 

Let (Tm-i ~^c(^m, and aj-^c(^j+i be the two corresponding execution steps in the original 
execution. 

Our inductive hypothesis guarantees that TBP{am,t) 5 TBP(cr^,t). But any concur- 
rent execution is guaranteed to be interference-free. Hence, it follows that TBP((Tj,t) 5 
TBP(cr,„,t). Hence, it follows that TBF{aj,t) D TBP(cr^.,t). 
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Now, if e is a conditional branch statement labelled with the statement "assume (/9", 
then we must have (o"j,t) \=c '■p- It follows that (o"^,i) |=c ^- (This follows because we use 
a basis that covers all branch conditions.) Thus, the second candidate execution step of Q 
is indeed a feasible execution step. 

that TBP(o-j+i,t) D TBP(CT;,^i,t). 



6.1 



It then follows from Lemma ^ _ _ 

Now, consider any pair of successive execution steps (y'^_i -^c cr^ ~^c '^'k+i °f C- Thus, 
we consider the first step executed by thread t^ after thread tft_i executes its last step. 

Note that TBP((T^, t/i_i) = TBP(c7^,i/i) (since none of the basis predicates at the 
quiescent vertex involve thread- local variables). 

Let dp -w^ CTp+i denote the corresponding, last, execution step performed by t^-i in 

the interleaved execution. Let Uj ^c <^j+i denote the corresponding, first, execution step 
performed by th in the interleaved execution. By the inductive hypothesis, TBP((Tp, th-i) 2 
TBP(a^,tft_i). 

Note that in the interleaved execution p may be less than or greater than j: th-i may 
or may not have completed execution by the time t^ performs its first execution step. Yet, 
we can establish that TBP((Tj,t/t) 5 TBP((t^, t/i_i). This is because no thread can execute 
a step that will change the value of any predicate in TBP(crp, th-i) between the last step of 
t/i_i and the first step of t^ (no matter how these two steps are ordered during execution). 

n 

Lemma 6.3. For t G {ti, • • • ,tfc}, the value returned by procedure invocation t in vri is the 
same as the value returned by t in the sequential execution 112 corresponding to schedule C,. 

(t,e) (t,e) 

Proof. Let aj-^c<yj+i and cr^-^cC^ 4.1 denote the execution of the return statements by t in 



vTi and 7r2 respectively, it follows from Lemma 6.2 that TBP(iTj,t) 5 TBP(cr^,t). Suppose 
that t returns a value c in the sequential execution 1:2- Note that we use a basis that covers 
all return statements. Hence, the predicate c == ret must be in TBP(cr^,t). It follows that 
c == ret must be in TBP((7j,t) as well. Hence, t returns c in tti as well. D 

Theorem 6.4. Given a library C that is totally correct with respect to a given sequential 
specification, the library C generated by our algorithm is linearizable with respect to the given 
specification. 



Proof. Follows immediately from Lemma 6.3 D 



The above theorem requires total correctness of the library in the sequential setting. 
E.g., consider a procedure P with a specification ensures x==0. An implementation that 
sets X to be 1, and then enters an infinite loop is partially correct with respect to this spec- 
ification (but not totally correct). In a concurrent setting, this can lead to non- linearizable 
behavior, since another concurrent thread can observe that x has value 1, which is not a 
legally observable value after procedure P completes execution. 

6.4. Discussion. In this section, we have presented a logical approach to synthesizing 
concurrency control to ensure linearizability/atomicity. In particular, we use predicates to 
describe what is relevant to ensure correctness (or desired properties). Predicates enable 
us to describe relevance in a more fine-grained fashion, creating opportunities for more 
concurrency. 
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We believe that this approach is promising and that there is significant scope for im- 
proving our solution and several interesting research directions worth pursuing. Indeed, 
some basic optimizations to the scheme presented may be critical to getting reasonable so- 
lutions. One example is an optimization relating to frame conditions, hinted at in Section [2j 
As an example, assume that x > is an invariant that holds true in between procedure 
invocations in a sequential execution. (Thus, this is a library invariant.) A procedure that 
neither reads or writes x will, nevertheless, have the invariant x > at every program point 
(to indicate that it never breaks this invariant). Our solution, as sketched, will require 
the procedure to acquire a lock on this predicate and hold it during the entire procedure. 
However, this is not really necessary, and can be optimized away. In general, the invariant 
or the basis at any program point may be seen as consisting of two parts, the frame and 
the footprint. The footprint relates to predicates that are relevant and/or may be modified 
by the procedure, while the frame simply indicates predicates that are irrelevant and left 
untouched by the procedure. We need to consider only the footprint in synthesizing the 
concurrency control solution. We leave fleshing out the details of such optimizations as 
future work. 

We conjecture that the extensions presented in this section to avoid control-flow inter- 
ference is not necessary to ensure linearizability. Indeed, note that if we can ensure that 
any concurrent execution is observationally equivalent and topologically equivalent to some 
sequential execution, this is suflicient. Our current technique ensures that the concurrent 
execution is also a permutation of the sequential execution: i.e., every procedure invocation 
follows the same execution path in both the concurrent and sequential execution. However, 
our current proof of correctness relies on this property. Relaxing this requirement is an 
interesting open problem. 

We believe that our technique can be adapted in a straight-forward fashion to work 
with linearization points other than the procedure entry (as long as the linearization point 
satisfies certain constraints). Different linearization points can potentially produce different 
concurrency control solutions. 

We also believe that with various of these improvements, we can synthesize the so- 
lution presented in Fig. [T] as a linearizable and atomic implementation, starting with no 
specification whatsoever. 

7. Related Work 

Synthesizing Concurrency Control: Vechev et al. ^24j present an approach for synthe- 
sizing concurrency control for a concurrent program, given a specification in the form of 
assertions in the program. This approach. Abstraction Guided Synthesis, generalizes the 
standard counterexample-guided abstraction refinement (CEGAR) approach to verification 
as follows. The algorithm attempts to prove that the concurrent program satisfies the de- 
sired assertions. If this fails, an interleaved execution that violates an assertion is identified. 
This counterexample is used to either refine the abstraction (as in CEGAR) or to restrict 
the program by adding some atomicity constraints. An atomicity constraint indicates that 
a context-switch should not occur at a given program point (thus requiring the statements 
immediately preceding and following the program point to be in an atomic-block) or is a 
disjunction of such constraints. Having thus refined either the abstraction or the program, 
the algorithm repeats this process. 
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Our work has the same high-level goal and philosophy as Vechev et al.: derive a con- 
currency control solution automatically from a specification of the desired correctness prop- 
erties. However, there are a number of differences between the two approaches. Before we 
discuss these differences, it is worth noting that the concrete problem addressed by these 
two papers are somewhat different: while our work focuses on making a sequential library 
safe for concurrent clients, Vechev et al. focus on adding concurrency control to a given 
concurrent program to make it safe. Thus, neither technique can be directly applied to the 
other problem, but we can still observe the following points about the essence of these two 
approaches. 

Both approaches are similar in exploiting verification techniques for synthesizing con- 
currency control. However, our approach decouples the verification step from the synthesis 
step, while Vechev et al. present an integrated approach that combines both. Our verifi- 
cation step requires only sequential reasoning, while the Vechev et al. algorithm involves 
reasoning about concurrent (interleaved) executions. Specifically, we exploit the fact that 
a sequential proof indicates what properties are critical at different program points (for a 
given thread) , which allows us to determine whether the execution of a particular statement 
(by another thread) constitutes (potentially) undesirable interference. 

We present a locking-based solution to concurrency control, while Vechev et al. present 
the solution in terms of atomic regions. Note that if our algorithm is parameterized to use 
a single lock (i.e., to map every predicate to the same lock), then the generated solution is 
effectively one based on atomic regions. 

Raza et al. [19] present an approach for automatically parallelizing a program that 
makes use of a separation logic proof. This approach exploits the separation logic based 
proof to identify whether candidate statements for parallelization access disjoint sets of 
locations. Like most classical approaches to automatic parallelization, this approach too 
relies on a data-based notion of interference, while our approach identifies a logical notion 
of interference. 

Several papers O HI [U [TBI fl^ [21] address the problem of inferring lock-based synchro- 
nization for atomic sections to guarantee atomicity. These existing lock inference schemes 
identify potential confiicts between atomic sections at the granularity of data items and 
acquire locks to prevent these conflicts, either all at once or using a two-phase locking ap- 
proach. Our approach is novel in using a logical notion of interference (based on predicates), 
which can permit more concurrency. 

|20j describes a sketching technique to add missing synchronization by iteratively ex- 
ploring the space of candidate programs for a given thread schedule, and pruning the search 
space based on counterexample candidates. [15j uses model-checking to repair errors in a 
concurrent program by pruning erroneous paths from the control-fiow graph of the inter- 
leaved program execution. [23] is a precursor to [24J, discussed above, that considers the 
tradeoff between increasing parallelism in a program and the cost of synchronization. This 
paper allows users to specify limitations on what may be used as the guard of conditional 
critical regions (the synchronization mechanism used in the paper), thus controlling the 
costs of synchronization. [6] allows users to specify synchronization patterns for critical 
sections, which are used to infer appropriate synchronization for each of the user-identified 
region. Vechev et al. [22] address the problem of automatically deriving linearizable ob- 
jects with fine-grained concurrency, using hardware primitives to achieve atomicity. The 
approach is semi-automated, and requires the developer to provide algorithm schema and 
insightful manual transformations. Our approach differs from all of these techniques in 
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exploiting a proof of correctness (for a sequential computation) to synthesize concurrency 
control that guarantees thread-safety. 

Verifying Concurrent Programs: Our proposed style of reasoning is closely related 
to the axiomatic approach for proving concurrent programs of Owicki & Gries [18j. While 
they focus on proving a concurrent program correct, we focus on synthesizing concurrency 
control. They observe that if two statements do not interfere, the Hoare triple for their 
parallel composition can be obtained from the sequential Hoare triples. Our approach 
identifies statements that may interfere and violate the sequential Hoare triples, and then 
synthesizes concurrency control to ensure that sequential assertions are preserved by parallel 
composition. 

Prior work on verifying concurrent programs \Vti has also shown that attaching in- 
variants to resources (such as locks and semaphores) can enable modular reasoning about 
concurrent programs. Our paper turns this around: we use sequential proofs (which are 
modular proofs, but valid only for sequential executions) to identify critical invariants and 
create locks corresponding to such invariants and augment the program with concurrency 
control that enables us to lift the sequential proof into a valid proof for the concurrent 
program. 



8. Limitations, Extensions, and Future Work 

In this paper, we have explored the idea that proofs of correctness for sequential compu- 
tations can yield concurrency control solutions for use when the same computations are 
executed concurrently. We have adopted simple solutions in a number of dimensions in 
order to focus on this central idea. A number of interesting ideas and problems appear 
worth pursuing in this regard, as explained below. 

Procedures. The simple programming language presented in Section [2] does not include 
procedures. The presence of procedure calls within the library gives rise to a different set 
of challenges. Verification tools often compute procedure summaries to derive the overall 
proof of correctness. Our approach could use summaries as proxies for procedure calls and 
derives concurrency control schemes where locks are acquired and released only in the top- 
level procedures. A more aggressive approach could analyze the proofs bottom up and infer 
nested concurrency control schemes where locks are acquired and released in procedures 
that subsume the lifetimes of the corresponding predicates. 

Relaxed Memory Models. The programming language semantics we use and our proofs 
assume sequential consistency. We believe it should be possible to extend the notion of 
logical interference to relaxed memory models. Under a relaxed model, reads may return 
more values compared to sequential consistent executions. Therefore, we may have to 
consider these additional behaviors while determining if a statement can interfere with (the 
proof of) a concurrent thread. We leave this extension for future work. 

Optimistic Concurrency Control. Optimistic concurrency control is an alternative to pes- 
simistic concurrency control (such as lock-based techniques) . While we present a lock-based 
pessimistic concurrency control mechanism, it would be interesting to explore the possibil- 
ity of optimistic concurrency control mechanisms that exploit a similar weaker notion of 
interference. 
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Choosing Good Solutions. This paper presents a space of valid locking solutions that guar- 
antee the desired properties. Specifically, the locking solution generated is dependent on 
several factors: the sequential proof used, the basis used for the proof, the mapping from 
basis predicates to locks, the linearization point used, etc. Given a metric on solutions, 
generating a good solution according to the given metric is a direction for future work. 
E.g., one possibility is to evaluate the performance of candidate solutions (suggested by our 
framework) using a suitable test suite to choose the best one. Integrating the concurrency 
control synthesis approach with the proof generation approach, as done by |24j, can also 
lead to better solutions, if the proofs themselves can be refined or altered to make the 
concurrency control more efficient. 

Fine- Grained Locking. Fine-grained locking refers to locking disciplines that use an un- 
bounded number of locks and associate each lock with a small number of shared objects 
(typically one). Programs that use fine-grained locking often scale better because of re- 
duced contention for locks. In its current form, the approach presented in this paper does 
not derive fine-grained locking schemes. The locking schemes we synthesize associate locks 
with predicates and the number of such predicates is statically bounded. Generalizing our 
approach to infer fine-grained locking from sequential proofs of correctness remains an open 
and challenging problem. 

Lightweight Specifications. Our technique relies on user-provided specifications for the li- 
brary. Recently, there has been interest in lightweight annotations that capture commonly 
used correctness conditions in concurrent programs (such as atomicity, determinism, and 
linearizability) . As we discuss in Section [ll we believe that there is potential for profitably 
applying our technique starting with such lightweight specifications (or even no specifica- 
tions). 

Glass invariants. In our approach, a thread holds a lock on a predicate from the point the 
predicate is established to the point after which the predicate is no longer used. While this 
approach ensures correctness, it may often be too pessimistic. For example, it is often the 
case that a library is associated with class/object invariants that characterize the stable 
state of the library's objects. Procedures in the library may temporarily break and then 
re-establish the invariants at various points during their invocation. If class invariants are 
known, it may be possible to derive more efficient concurrency control mechanisms that 
release locks on the class invariants at points where the invariants are established and 
re-acquire these locks when the invariants are used. Such a scheme works only when all 
procedures "co-operate" and ensure that the locks associated with the invariants are released 
only when the invariant is established. 
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